Is there a way to put a command window in the background like Linux does (so that you can kill it)?

[Andy Burnelli]

Is there a way to put a command window in the background like Linux does
with the ampersand (so that you can kill the window but not the process)?

The problem that I have is I run a lot of commands from the Run icon in my
taskbar which bring up command windows to run scxripts but which leave
the unnecessary command window sitting around (which can be iconified).
<https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

As an example, for years I've been running commands from a shortcut target
such as this target below which end up leaving an open command window in the
taskbar after they call the process, which itself opens up its own window.
%comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555

That reliably pops up the Android screen on Windows over Wi-Fi but then I
have absolutely no need for the command window to remain around as clutter.

Is there a way to get rid of the command Window and not kill the process?

In UNIX, I used to use the ampersand (&) to background the process.
The I could easily close the window & the background process would remain.

Does Windows have that concept of putting the command in the background so
that the window that called it can be closed (but the process remains)?

I have the same issue with openvpn windows where I don't need the extraneous
running open command window cluttering up what otherwise should be a clean
Windows user experience. I never enter another command in those windows.

And yet, I can accidentally interfere with the open window because it's
there and you can't get rid of it (other than to iconify it with the (-),
but it's still there on the otherwise clean taskbar, just waiting to be
opened by accident (and the icon looks like all other cmd window icons).

For those reasons...

Is there a way to background a Windows command (e.g., "&") and then we can
safely _close_ that extraneous running command window to reduce clutter?
--
Usenet is where kind-hearted people daily gather to voluntarily help others.

[Kerr-Mudd, John]

On Thu, 21 Apr 2022 18:42:52 +0100
Andy Burnelli <sp...@nospam.com> wrote:

> Is there a way to put a command window in the background like Linux does
> with the ampersand (so that you can kill the window but not the process)?
>
> The problem that I have is I run a lot of commands from the Run icon in my
> taskbar which bring up command windows to run scxripts but which leave
> the unnecessary command window sitting around (which can be iconified).
> <https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)
>
> As an example, for years I've been running commands from a shortcut target
> such as this target below which end up leaving an open command window in the
> taskbar after they call the process, which itself opens up its own window.
> %comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555
>
> That reliably pops up the Android screen on Windows over Wi-Fi but then I
> have absolutely no need for the command window to remain around as clutter.
>

So why put in the parameter '/k'?

> Is there a way to get rid of the command Window and not kill the process?

Just never open it in the first place?

> In UNIX, I used to use the ampersand (&) to background the process.
> The I could easily close the window & the background process would remain.
>
> Does Windows have that concept of putting the command in the background so
> that the window that called it can be closed (but the process remains)?
>
> I have the same issue with openvpn windows where I don't need the extraneous
> running open command window cluttering up what otherwise should be a clean
> Windows user experience. I never enter another command in those windows.
>
> And yet, I can accidentally interfere with the open window because it's
> there and you can't get rid of it (other than to iconify it with the (-),
> but it's still there on the otherwise clean taskbar, just waiting to be
> opened by accident (and the icon looks like all other cmd window icons).
>
> For those reasons...
>
> Is there a way to background a Windows command (e.g., "&") and then we can
> safely _close_ that extraneous running command window to reduce clutter?
> --
> Usenet is where kind-hearted people daily gather to voluntarily help others.

--
Bah, and indeed Humbug.

[Andy Burnelli]

Kerr-Mudd, John wrote:

>> That reliably pops up the Android screen on Windows over Wi-Fi but then I
>> have absolutely no need for the command window to remain around as clutter.
>>
>
> So why put in the parameter '/k'?

Good question.

The /k is mostly habit but it doesn't matter as you must use either /K or /C
and both do the exact same thing with respect to the window staying open.

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555

As a direct result of your query, I changed it to /c (you must use one or
the other as far as I know), but I knew it wouldn't matter as I've had this
problem for decades. I just never tried to resolve it until now.

The way Linux gets around it is the put the command in the background.
But I don't know how to put a Windows command in the background.

Does anyone know how to background a Windows command?

There might be something in the help for comspec though on the Linux-like
use of ampersand (&) to put the process into the background so that the
initiating command window can subsequently be closed.
%comspec% /? > comspec.man (See output in the sig.)

>> Is there a way to get rid of the command Window and not kill the process?
>
> Just never open it in the first place?

That would work if I knew how to run a command without ever opening a
command window. How is that done for the screen copy command shown above?
--
%comspec% /? > comspec.man

Starts a new instance of the Windows command interpreter

CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] string]

/C Carries out the command specified by string and then terminates
/K Carries out the command specified by string but remains
/S Modifies the treatment of string after /C or /K (see below)
/Q Turns echo off
/D Disable execution of AutoRun commands from registry (see below)
/A Causes the output of internal commands to a pipe or file to be ANSI
/U Causes the output of internal commands to a pipe or file to be
Unicode
/T:fg Sets the foreground/background colors (see COLOR /? for more info)
/E:ON Enable command extensions (see below)
/E:OFF Disable command extensions (see below)
/F:ON Enable file and directory name completion characters (see below)
/F:OFF Disable file and directory name completion characters (see below)
/V:ON Enable delayed environment variable expansion using ! as the
delimiter. For example, /V:ON would allow !var! to expand the
variable var at execution time. The var syntax expands variables
at input time, which is quite a different thing when inside of a FOR
loop.
/V:OFF Disable delayed environment expansion.

Note that multiple commands separated by the command separator '&&'
are accepted for string if surrounded by quotes. Also, for compatibility
reasons, /X is the same as /E:ON, /Y is the same as /E:OFF and /R is the
same as /C. Any other switches are ignored.

If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:

1. If all of the following conditions are met, then quote characters
on the command line are preserved:

- no /S switch
- exactly two quote characters
- no special characters between the two quote characters,
where special is one of: &<>()@^|
- there are one or more whitespace characters between the
two quote characters
- the string between the two quote characters is the name
of an executable file.

2. Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.

If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun

and/or

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

Command Extensions are enabled by default. You may also disable
extensions for a particular invocation by using the /E:OFF switch. You
can enable or disable extensions for all invocations of CMD.EXE on a
machine and/or user logon session by setting either or both of the
following REG_DWORD values in the registry using REGEDIT.EXE:

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions

and/or

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions

to either 0x1 or 0x0. The user specific setting takes precedence over
the machine setting. The command line switches take precedence over the
registry settings.

In a batch file, the SETLOCAL ENABLEEXTENSIONS or DISABLEEXTENSIONS
arguments
takes precedence over the /E:ON or /E:OFF switch. See SETLOCAL /? for
details.

The command extensions involve changes and/or additions to the following
commands:

DEL or ERASE
COLOR
CD or CHDIR
MD or MKDIR
PROMPT
PUSHD
POPD
SET
SETLOCAL
ENDLOCAL
IF
FOR
CALL
SHIFT
GOTO
START (also includes changes to external command invocation)
ASSOC
FTYPE

To get specific details, type commandname /? to view the specifics.

Delayed environment variable expansion is NOT enabled by default. You
can enable or disable delayed environment variable expansion for a
particular invocation of CMD.EXE with the /V:ON or /V:OFF switch. You
can enable or disable delayed expansion for all invocations of CMD.EXE on a
machine and/or user logon session by setting either or both of the
following REG_DWORD values in the registry using REGEDIT.EXE:

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\DelayedExpansion

and/or

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\DelayedExpansion

to either 0x1 or 0x0. The user specific setting takes precedence over
the machine setting. The command line switches take precedence over the
registry settings.

In a batch file the SETLOCAL ENABLEDELAYEDEXPANSION or
DISABLEDELAYEDEXPANSION
arguments takes precedence over the /V:ON or /V:OFF switch. See SETLOCAL /?
for details.

If delayed environment variable expansion is enabled, then the exclamation
character can be used to substitute the value of an environment variable
at execution time.

You can enable or disable file name completion for a particular
invocation of CMD.EXE with the /F:ON or /F:OFF switch. You can enable
or disable completion for all invocations of CMD.EXE on a machine and/or
user logon session by setting either or both of the following REG_DWORD
values in the registry using REGEDIT.EXE:

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\CompletionChar
HKEY_LOCAL_MACHINE\Software\Microsoft\Command
Processor\PathCompletionChar

and/or

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\CompletionChar
HKEY_CURRENT_USER\Software\Microsoft\Command
Processor\PathCompletionChar

with the hex value of a control character to use for a particular
function (e.g. 0x4 is Ctrl-D and 0x6 is Ctrl-F). The user specific
settings take precedence over the machine settings. The command line
switches take precedence over the registry settings.

If completion is enabled with the /F:ON switch, the two control
characters used are Ctrl-D for directory name completion and Ctrl-F for
file name completion. To disable a particular completion character in
the registry, use the value for space (0x20) as it is not a valid
control character.

Completion is invoked when you type either of the two control
characters. The completion function takes the path string to the left
of the cursor appends a wild card character to it if none is already
present and builds up a list of paths that match. It then displays the
first matching path. If no paths match, it just beeps and leaves the
display alone. Thereafter, repeated pressing of the same control
character will cycle through the list of matching paths. Pressing the
Shift key with the control character will move through the list
backwards. If you edit the line in any way and press the control
character again, the saved list of matching paths is discarded and a new
one generated. The same occurs if you switch between file and directory
name completion. The only difference between the two control characters
is the file completion character matches both file and directory names,
while the directory completion character only matches directory names.
If file completion is used on any of the built in directory commands
(CD, MD or RD) then directory completion is assumed.

The completion code deals correctly with file names that contain spaces
or other special characters by placing quotes around the matching path.
Also, if you back up, then invoke completion from within a line, the
text to the right of the cursor at the point completion was invoked is
discarded.

The special characters that require quotes are:
<space>
&()[]{}^=;!'+,`~

[Herbert Kleebauer]

On 21.04.2022 22:57, Andy Burnelli wrote:
> Kerr-Mudd, John wrote:
>
>>> That reliably pops up the Android screen on Windows over Wi-Fi but then I
>>> have absolutely no need for the command window to remain around as clutter.
>>>
>>
>> So why put in the parameter '/k'?
>
> Good question.
>
> The /k is mostly habit but it doesn't matter as you must use either /K or /C
> and both do the exact same thing with respect to the window staying open.
>
> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555
>
> As a direct result of your query, I changed it to /c (you must use one or
> the other as far as I know), but I knew it wouldn't matter as I've had this
> problem for decades. I just never tried to resolve it until now.

It should matter. But I suppose scrcpy is a GUI program which will not
terminate itself. But if you exit scrcpy, then the CMD should also be closed.
If you don't want that the CMD windows stays open, then use "start scrcpy".

[Andy Burnelli]

Herbert Kleebauer wrote:

> It should matter.

Well, to be clear, the "/c" vs "/k" matters sometimes.
But not in the case of GUI programs, as you already surmised.

> But I suppose scrcpy is a GUI program which will not
> terminate itself.

If I terminate the mirrored Android GUI window, the command window stays
open even as the scrcpy command running inside of it exits. If I instead
terminate that command window, then both the command window and the scrcpy
mirrored GUI are terminated.

> But if you exit scrcpy, then the CMD should also be closed.

In Linux, I'd simply add an ampersand (&) to the end of the scrcpy command.
That backgrounds the command such that killing the command window doesn't
affect any process which is running in the background (which then can be
brought to the fore when needed).

> If you don't want that the CMD windows stays open, then use "start scrcpy".

Hmmmmm.... gonna have to look that one up... and test to see if that works.

<https://stackoverflow.com/questions/8121238/start-comspec-c-script-cmd-vs-start-cmd-c-script-cmd>
"What is the difference between following commands:"
"start %comspec% /c script.cmd
"start cmd /C script.cmd"
"I need that cmd window for script.cmd should close automatically
when script.cmd is finished."
Drat. It's the right question, but all the "answers" are off topic.
(And the OP didn't chastise them for that. So there's no answer there.)

Given "Win+R > start" fails to find the executable, let me look for the
path... oh, geez, it's not an exexcutable in the normal sense of the word.
dir /s/a/l/on/b C:\Windows\*.* | findstr "start"

Ah! "start" is a special _internal_ command (much like "ver" is internal).
<https://www.computerhope.com/jargon/i/intecomm.htm>

That means "start" works _only_ inside an existing command window.
<https://www.computerhope.com/starthlp.htm>

So there's no way to use "start" without _first_ opening a command window.

I'm working on getting the syntax right to either call the shortcut.lnk
directly from the "Run" icon pinned to my taskbar, or, failing that, to pass
the "start" to the command window via the "Run" icon pinned to my taskbar.

The syntax isn't as easy to figure out as I would have thought due to the
parallel nature of the run command, complicated by the fact it is an
"internal command" so it only works _after_ the command window is opened.
--
<https://ss64.com/nt/start.html>
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start>
<https://www.howtogeek.com/tips/how-to-run-a-scheduled-task-without-a-command-window-appearing/>
<https://www.windows-commandline.com/cmd-start-command/>

[Andy Burnelli]

Andy Burnelli wrote:

> The syntax isn't as easy to figure out as I would have thought due to the
> parallel nature of the run command, complicated by the fact it is an
> "internal command" so it only works _after_ the command window is opened.

Ooops. To be clear... I meant the "start" command is parallel in nature.

Anyway, the problem is the parallel start syntax won't work in the Windows
Run box or in the shortcut TARGET field (so far, anyway on my need for a
linear "cd & adb & scrcpy" command sequence).

Working on that syntax right now... but if you've never tried to use the
internal "start" command, you might not realize that it fails 100% of the
time (so far) if you haven't figured out its arcane syntax requirements
(which I haven't figured out yet).

As one syntax example, apparently "start" _must_ be used _only_ with "/k".
<https://ss64.com/nt/start.html>
Otherwise, there's nothing left for remaining commands to run inside of.

And if you google for start syntax examples, they're all too simple:
<https://www.windows-commandline.com/cmd-start-command/>
Bear in mind, zero of these examples work in the "Run" box (so far anyway).

[Herbert Kleebauer]

On 22.04.2022 03:07, Andy Burnelli wrote:

>
>> If you don't want that the CMD windows stays open, then use "start scrcpy".
>
> Hmmmmm.... gonna have to look that one up... and test to see if that works.

start /?

Why don't you just try your command with an added "start" before "scrcpy":

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

If the CMD window still doesn't close, add a "&cls&exit"

[Andy Burnelli]

Herbert Kleebauer wrote:

>>> If you don't want that the CMD windows stays open, then use "start scrcpy".
>>
>> Hmmmmm.... gonna have to look that one up... and test to see if that works.
>
> start /?

I think perhaps this task of killing the window is harder than it seems to be.

I ran that and I referenced all the online manpages; however, I haven't
_understood_ yet all the options, nor have I figured out which will work.

> Why don't you just try your command with an added "start" before "scrcpy":
> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

Well, that _was_ the first thing I had tried; but all it did when I tried it
was _add_ another command window (which closed instantly); but otherwise
there was no change (in that what's left is the command window & the Android mirror).

> If the CMD window still doesn't close, add a "&cls&exit"

I think it may be harder to do than it at first appears to be.

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & cls & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit
Unfortunately they still left the command window the same as before.

What they apparently killed was the penultimate adb server window
(whose standard out used to be combined with the scrcpy window apparently).

However clearing the screen and exiting _again_ didn't solve that issue
of the lingering command window when run from the "Run" icon:
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & cls & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & exit

It's interesting that with the &cls&exit, the adb output is missing;
but it still doesn't prevent the command window from lingering. Sigh.
--
& separates commands on a line.
&& executes this command only if previous command's errorlevel is 0.
|| (not used above) executes this command only if previous command's errorlevel is NOT 0
> output to a file
>> append output to a file
< input from a file
| output of one command into the input of another command
^ escapes any of the above, including itself, if needed to be passed to a program
" parameters with spaces must be enclosed in quotes
+ used with copy to concatenate files. E.G. copy file1+file2 newfile
, used with copy to indicate missing parameters. This updates the files modified date. E.G. copy /b file1,,
%variablename% a inbuilt or user set environmental variable
!variablename! a user set environmental variable expanded at execution time, turned with SetLocal EnableDelayedExpansion command
%<number> (%1) the nth command line parameter passed to a batch file. %0 is the batchfile's name.
%* (%*) the entire command line.
%<a letter> or %%<a letter> (%A or %%A) the variable in a for loop. Single % sign at command prompt and double % sign in a batch file.

[Andy Burns]

Andy Burnelli wrote:

> I think it may be harder to do than it at first appears to be.

You're trying to do stuff that's kind of beyond CMD's capability, you can do
more with WSH (windows script host) or Powershell, if you haven't used WSH
before, I wouldn't recommend starting now, it's a dead-end.

A starting point, if it's of interest, there are many other ways to skin the cat

<https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7.2>

[Herbert Kleebauer]

On 22.04.2022 10:32, Andy Burnelli wrote:

> Herbert Kleebauer wrote:
>
>> Why don't you just try your command with an added "start" before "scrcpy":
>> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

I don't know how you enter this command. If you type <WIN>R and enter the
following line:

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && start notepad

notepad is started and the CMD window then closed. If you remove the
"start", the CMD window stays open until you exit notepad.

If you enter this command in an already open CMD window, then
it doesn't make any sense to start a new CMD window, just start a
batch with this content (or directly type the lines in the
open CMD window):

cd /d "c:\app\editor\android\scrcpy"

adb connect 192.168.0.2:5555

start scrcpy --always-on-top --tcpip=192.168.0.2:5555

exit

[MikeS]

I do what I think the OP wants by using this free utility:
https://www.robvanderwoude.com/files/consolestate.zip
https://www.robvanderwoude.com/helptext.php?src=consolestate_cs_help

A simple command line would be:
%comspec% /k cd /d "D:\" && consolestate.exe /Hide && Notepad.exe
which will run Notepad and leave it open but hide the command window.

[Kerr-Mudd, John]

On Fri, 22 Apr 2022 13:06:39 +0100
MikeS <Mi...@fred.com> wrote:

> On 22/04/2022 10:23, Andy Burns wrote:
> > Andy Burnelli wrote:
> >
> >> I think it may be harder to do than it at first appears to be.
> >
> > You're trying to do stuff that's kind of beyond CMD's capability, you
> > can do more with WSH (windows script host) or Powershell, if you haven't
> > used WSH before, I wouldn't recommend starting now, it's a dead-end.
> >
> > A starting point, if it's of interest, there are many other ways to skin
> > the cat
> >
> > <https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7.2>
> >
> >
> I do what I think the OP wants by using this free utility:
> https://www.robvanderwoude.com/files/consolestate.zip
> https://www.robvanderwoude.com/helptext.php?src=consolestate_cs_help

requires .Net

Just saying.

>
> A simple command line would be:
> %comspec% /k cd /d "D:\" && consolestate.exe /Hide && Notepad.exe
> which will run Notepad and leave it open but hide the command window.

[Andy Burnelli]

Herbert Kleebauer wrote:

>>> Why don't you just try your command with an added "start" before "scrcpy":
>>> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555
>
> I don't know how you enter this command.

Thanks for asking where I first test it in Win+R (only I have the "Run" icon pinned to my taskbar as shown in the graphic previously presented).
<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> An efficient program setup

Once it works in the "Run" box, then I put it into a shortcut TARGET field.
(See the graphic above and below for those steps, as previously documented.)
<https://i.postimg.cc/Vvrq0K0m/scrcpy03.jpg> The efficient setup explained

> If you type <WIN>R and enter the
> following line:
>
> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && start notepad
>
> notepad is started and the CMD window then closed.

Yup. But that's so easy, this does something similar but w/o the cmd window _needing_ to be opened (the point being that's far too easy of an example).
<https://i.postimg.cc/m2mYw789/notepad01.jpg>

Win+R > xx
Where "xx" is previously defined in the Windows registry for efficency as:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\xx.exe
@Default === C:\app\editor\txt\notepad++\notepad++.exe

For whatever reason, with the scrcpy command (which has to have adb prior),
it's not as easy to do as I would have hoped it would be, unfortunately.

> If you remove the
> "start", the CMD window stays open until you exit notepad.

I understand, but I think this is a deeper level problem set than the mere opening of a graphical tool.

An hint of the added layer of complexity is that when I used the start and killed the command window like you kindly had suggested, I noticed that the "adb" stdout didn't show up anymore in the remaining window (and, that a third window popped up and died instantly), and that the exit caused the stdout from adb (not scrcpy mind you, but adb) to be missing.

I know this because without the "start" & "&exit" stuff, adb would stay in the scrcpy command window and the kill-server of adb would also stay when the mirrored Android window was closed.

But with the "start" & "&exit", both of those stdout outputs disappeared.
(Clearly they were being fed to a window that was already closed.)

The point being that this is a bit more complicated than people think it is.

> If you enter this command in an already open CMD window, then
> it doesn't make any sense to start a new CMD window, just start a
> batch with this content (or directly type the lines in the
> open CMD window):
>
> cd /d "c:\app\editor\android\scrcpy"
> adb connect 192.168.0.2:5555
> start scrcpy --always-on-top --tcpip=192.168.0.2:5555
> exit

Let's keep in mind that efficiency and simplicity is the goal, always.
Let's try the sequence above to see what it does:

0. With the phone fifty feet away on a charger (but on Wi-Fi)
1. Run > cmd
2. C:\> ping 192.168.0.2 (don't worry about this technicality)
3. cd /d "c:\app\editor\android\scrcpy"
4. adb kill-server (don't worry about that technicality)
5. adb connect 192.168.0.2:5555
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.0.2:5555
6. start scrcpy --always-on-top --tcpip=192.168.0.2:5555

BTW, I probably do not need to specify the port the second
time in that sequence above; but I do it twice just in case.

Note that brings up two windows, one of which is the mirrored
Android window, and the other of which is the "scrcpy.exe" command window:
c:\app\editor\android\scrcpy\scrcpy.exe <== in the title bar
scrcpy 1.23 <https://github.com/Genymobile/scrcpy>
INFO: Connecting to 192.168.0.2:5555...
INFO: Connected to 192.168.0.2:5555
c:\app\editor\android\scrcpy\scrcpy-server: 1 file pushed, 0 skipped. 41.2 MB/s (41123 bytes in 0.001s)
[server] INFO: Device: samsung SM-A326U (Android 11)
INFO: Renderer: direct3d
INFO: Initial texture: 720x1600

Then I click the cursor to make the focus the command window & type:
7. exit

No go. You can't type _anything_ into the command window.
Nothing takes.

I had never _tried_ it before; but try as I might, the _only_ thing
you can do in that scrcpy command window is operate the Windows
border X box [x] and iconify box [-] and largify box [o].

I repeat. There is no possibility of typing _anything_ in that
scrcpy opened command window. I didn't know that before now.

Thank you for edifying me as I try _all_ reasonable suggestions.
And I report back what I found out (like all good netizens should).

In summary, I don't think this is as easy as it appears to be.

[Herbert Kleebauer]

On 22.04.2022 23:26, Andy Burnelli wrote:

> Note that brings up two windows, one of which is the mirrored
> Android window, and the other of which is the "scrcpy.exe" command window:

Then scrcpy.exe uses both, a GUI window and a console. But that has
nothing to do with the CMD window. You can't close this console because
the program needs it (maybe for some status or error output).

If you start scrcpy.exe by a mouse click, both windows should be created.
If you start it within a CMD window, scrcpy.exe should use the CMD
window as console, so no new console is created and CMD is suspended until
scrcpy.exe is closed. If you start it with "start scrcpy.exe" in a cmd
window, then a new console is created and CMD get control back over its
console immediately.

[Andy Burnelli]

Herbert Kleebauer wrote:

>> Note that brings up two windows, one of which is the mirrored
>> Android window, and the other of which is the "scrcpy.exe" command window:
>
> Then scrcpy.exe uses both, a GUI window and a console.
> But that has nothing to do with the CMD window.

Everything you said is correct.
Hence I apologize for being confused prior. Thank you for clarifying.

You (and Andy Burns) know more about Windows & command actions than I ever
will know, so I sincerely want to thank you for your kind-hearted help.

You are right. I was wrong. I ran all your tests (see below) and they worked
_exactly_ as you surmised they would.

> You can't close this console because
> the program needs it (maybe for some status or error output).

Yes. You are correct. I will give up on trying to close the "scrcpy console"
as the developers, for whatever reason, _want_ it to remain visible.

It's rare for me to fail to wrest control of Windows, but in this case, I
will admit defeat in that I can't get rid of that "scrcpy console" window
(other than to iconify it).

> If you start scrcpy.exe by a mouse click, both windows should be created.

You are correct.
The total number of windows depends on _how_ I run the command.

1. There is whatever "thing" the command is run inside of
a. That can be a CMD window
b. That can be a RUN box
c. That can be a shortcut TARGET
2. Then there is the "scrcpy console" window.
3. And then there is the resulting Android GUI.

As you correctly surmised, depending on _where_ I execute the scrcpy
command, the result could be two or three windows; but in every case, I
can't "kill" the scrcpy console (which was my original goal).

> If you start it within a CMD window, scrcpy.exe should use the CMD
> window as console, so no new console is created and CMD is suspended until
> scrcpy.exe is closed.

This is correct.

Here is a step-by-step test with the phone on the Wi-Fi network.
A. Run > cmd
B. ping 192.168.0.2 (just to ensure the TCP/IP connection is alive)
C. cd c:\app\editor\android\scrcpy
D. adb kill-server (this gives me a known baseline starting point)
E. adb connect 192.168.0.2:5555 (this returns me to the cmd prompt)
F. scrcpy (the CMD window turns into a scrcpy console)

As you correctly surmised, that does _two_ things:
1. The "scrcpy" console takes over the CMD window.
2. The Android GUI pops up

Then, when I press the Windows [x] box in the Android GUI...
1. That [x] kills the Android GUI window
2. And it kills the scrcpy process in the CMD window
3. Which gets me back the command prompt in the CMD window

> If you start it with "start scrcpy.exe" in a cmd
> window, then a new console is created and CMD get control back over its
> console immediately.

You are correct.

Here is a step-by-step test with the phone on the Wi-Fi network.
A. Run > cmd
B. ping 192.168.0.2
C. cd c:\app\editor\android\scrcpy
D. adb kill-server
E. adb connect 192.168.0.2:5555 (this returns me to the cmd prompt)
F. start scrcpy (this opens up a _separate_ scrcpy console)

That does _three_ things:
1. It opens up a _new_ console for the "scrcpy" output.
2. The Android GUI pops up
3. And it returns me to the cmd prompt in the cmd window
(I can close that command window without affecting anything else.)

Likewise, three windows open up if I put this in a shortcut TARGET:
TARGET= %comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555
a. It opens a cmd window
b. It opens a separate scrcpy console
c. It opens the Android GUI

The cmd window can be killed separately but killing either the Android GUI
or the scrpcpy console will kill both.

Lastly, this opens up three windows but instantly kills one of them:
TARGET= %comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 &cls&exit
a. It opens a cmd window
b. It opens a separate scrcpy console
c. It opens the Android GUI
d. Then it kills the cmd window

In summary, you were always correct and I was confused - but in the end, I
agree with you on everything you've tried to help me to understand.

The net is that I can't easily get rid of the scrcpy console.
Thanks for your kind help and advice.

[Andy Burnelli]

Zaidy036 wrote:

>> Is there a way to background a Windows command (e.g., "&") and then we can
>> safely _close_ that extraneous running command window to reduce clutter?
>

> Use Schtasks and select "hide" then run from shortcut

This works to bring up the Android GUI using the Task Scheduler.
But it still creates two windows (scrcpy console and Android GUI).

Create shortcut:
TARGET=C:\Windows\System32\schtasks.exe /run /TN "task scrcpy_1"
Name=task scrcpy

Doubleclick on that shortcut "task scrcpy.lnk" to execute it.

Run > taskschd.msc > Task Scheduler Library > RMB Create Task >
General:
Name = task scrcpy
[x]Hidden
Actions > New
Action = Start a program
Program/script = %comspec%
Add arguments = /c start "" adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555
Start in = c:\app\editor\android\scrcpy

Note that whether or not the [x]Hidden" box was checked,
the result was the same two windows.
a. The scrcpy console window
b. The Android GUI window

This didn't work because it killed all the windows.
Add arguments = /c start "" adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555 &cls&exit

[Andy Burnelli]

Andy Burnelli wrote:

> Create shortcut:
> TARGET=C:\Windows\System32\schtasks.exe /run /TN "task scrcpy_1"

Typo (as I had named each test "task scrcpy_1", "task scrcpy_2", etc.

Correction:

TARGET=C:\Windows\System32\schtasks.exe /run /TN "task scrcpy"

The end result is that the Task Scheduler "[x]Hidden" option didn't seem to
do anything useful in terms of whether or not the "scrcpy console" remained
open and alive after the "task scrcpy" shortcut was doubleclicked.

Sigh.
At this point I think I will give up on trying to get rid of the "scrcpy
console" window. I'll just manually iconify it when it pops up each time.

[Robert Roland]

On Thu, 21 Apr 2022 18:42:52 +0100, Andy Burnelli <sp...@nospam.com>
wrote:

>Is there a way to get rid of the command Window and not kill the process?

Herbert has already nailed it, but let me elaborate a bit.

In Windows, there are two types of programs: Console applications and
pure GUI applications.

It is not always easy to spot which is which, because a console
application can also create graphical windows.

A console application tells Windows that it needs a console, and
Windows will provide one. In Task Manager, you will see conhost.exe,
which is Windows' console. Some people think CMD.EXE is the console,
but it is not. CMD.EXE is just a console application. It requires
conhost.exe, just like the other console applications.

Your scrcpy program is a console application. It needs the console in
order to live. Like all console applications, if you kill the console,
the applications also dies.

There are ways to hide a window. There is a fourth "windowstyle" in
addition to "Maximized", "Minimized" and "Normal". It is called
"Hidden".

In your case, you mentioned that closing the graphical window will not
terminate the application. If the console window is hidden, this might
mean that you will have no way of terminating the application other
than killing it in Task Manager.

How do you normally terminate the application?
--
RoRo

[Andy Burnelli]

Robert Roland wrote:

> In Windows, there are two types of programs: Console applications and
> pure GUI applications.
>
> It is not always easy to spot which is which, because a console
> application can also create graphical windows.
>
> A console application tells Windows that it needs a console, and
> Windows will provide one. In Task Manager, you will see conhost.exe,
> which is Windows' console. Some people think CMD.EXE is the console,
> but it is not. CMD.EXE is just a console application. It requires
> conhost.exe, just like the other console applications.
>
> Your scrcpy program is a console application. It needs the console in
> order to live. Like all console applications, if you kill the console,
> the applications also dies.

Wow. That was a very nice explanation. Thank you for helping out.

> There are ways to hide a window. There is a fourth "windowstyle" in
> addition to "Maximized", "Minimized" and "Normal". It is called
> "Hidden".

When you say "window" in that sentence, with respect to the option of having
that window be "hidden", can the scrcpy "console" window be hidden?

> In your case, you mentioned that closing the graphical window will not
> terminate the application.

Actually, if I said that, I was wrong.
a. Closing the graphical Android window will close the scrcpy console too.
b. And vice versa. Closing the scrcpy console will close the Android GUI.

> If the console window is hidden, this might
> mean that you will have no way of terminating the application other
> than killing it in Task Manager.

Actually, hiding the scrcpy console window is _exactly_ what I want.
There isn't any way to interact with it (AFAIK); so it's just a waste
(IMHO). I'm sure the developers think it's useful; but I don't see any value
in it so I Minimize it but that means I still have to deal with it being
there adding to clutter on my taskbar.

> How do you normally terminate the application?

Normally I hit the "[x]" button on the Window of the graphical Android GUI.
That kills both the Android GUI window & the scrcpy console window.

How can I tell the "scrcpy console" to be hidden?

[Herbert Kleebauer]

On 23.04.2022 14:36, Andy Burnelli wrote:

> The net is that I can't easily get rid of the scrcpy console.

I don't understand why you want to hide the console, but this
should do it (untested, I don't have a program which uses
a GUI window and a console). Just start the below batch.
If it works, you can store showwin.exe somewhere in your
PATH, so you don't have to create it temporarily every
time you execute the batch. I post the usage of showwin.exe
in a follow up.


@echo off
certutil -f -decode %~f0 showwin.exe>nul

cd /d "c:\app\editor\android\scrcpy"

adb connect 192.168.0.2:5555

:: now we hide console window
showwin.exe 0

scrcpy --always-on-top --tcpip=192.168.0.2:5555

:: after scrcpy is closed we show console window again
showwin.exe 5

del showwin.exe
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----

[Herbert Kleebauer]

On 23.04.2022 17:04, Herbert Kleebauer wrote:

> I post the usage of showwin.exe

@echo off
:: minimize/maximize/hide the command window (requires W2k or better).
::
:: Usage: showwin.exe number
::
:: 0 SW_HIDE
:: Hides the window and activates another window.
::
:: 1 SW_SHOWNORMAL
:: Activates and displays a window. If the window is minimized or maximized,
:: the system restores it to its original size and position. An application
:: should specify this flag when displaying the window for the first time.
::
:: 2 SW_SHOWMINIMIZED
:: Activates the window and displays it as a minimized window.
::
:: 3 SW_MAXIMIZE
:: Maximizes the specified window.
::
:: 3 SW_SHOWMAXIMIZED
:: Activates the window and displays it as a maximized window.
::
:: 4 SW_SHOWNOACTIVATE
:: Displays a window in its most recent size and position. This value is
:: similar to SW_SHOWNORMAL, except the window is not actived.
::
:: 5 SW_SHOW
:: Activates the window and displays it in its current size and position.
::
:: 6 SW_MINIMIZE
:: Minimizes the specified window and activates the next top-level window
:: in the Z order.
::
:: 7 SW_SHOWMINNOACTIVE
:: Displays the window as a minimized window. This value is similar to
:: SW_SHOWMINIMIZED, except the window is not activated.
::
:: 8 SW_SHOWNA
:: Displays the window in its current size and position. This value is
:: similar to SW_SHOW, except the window is not activated.
::
:: 9 SW_RESTORE
:: Activates and displays the window. If the window is minimized or maximized,
:: the system restores it to its original size and position. An application
:: should specify this flag when restoring a minimized window.
::
:: 10 SW_SHOWDEFAULT
:: Sets the show state based on the SW_ value specified in the STARTUPINFO
:: structure passed to the CreateProcess function by the program that
:: started the application.
::
:: 11 SW_FORCEMINIMIZE
:: Windows 2000/XP: Minimizes a window, even if the thread that owns the
:: window is not responding. This flag should only be used when minimizing
:: windows from a different thread.

certutil -f -decode %~f0 showwin.exe>nul

cls
dir
:: wait 4 seconds
ping -n 4 localhost >nul
:: hide window
showwin.exe 0
dir /b
:: wait 4 seconds
ping -n 4 localhost >nul
:: show window
showwin.exe 5
:: wait 4 seconds
ping -n 4 localhost >nul

The source code:

winmain::
jsr.l (GetCommandLine)
; skip program name
eor.l r1,r1 ; not within "" flag
dec.l r0
_20: inc.l r0
cmp.b #0,(r0)
beq.b _10
cmp.b #'"',(r0)
bne.b _30
not.l r1
_30: or.l r1,r1
bne.b _20
cmp.b #' ',(r0)
bne.b _20
inc.l r0

_10: eor.l r5,r5
move.l #5,r4 ; default: SW_SHOW
_50: movu.bl (r0),r1
inc.l r0
or.b r1,r1
beq.b _40
sub.b #'0',r1
bcs.b _50
cmp.b #9,r1
bhi.b _50
mulsq.l #10,r5,r5
add.l r1,r5
eor.l r4,r4
br.b _50
_40: or.l r4,r4
beq.b _60
move.l r4,r5

_60: jsr.l (GetConsoleWindow)

move.l r5,-(sp)
move.l r0,-(sp)
jsr.l (ShowWindow)

moveq.l #0,-(sp)
jsr.l (ExitProcess) ; exit program

[Herbert Kleebauer]

On 23.04.2022 17:04, Herbert Kleebauer wrote:

> @echo off
> certutil -f -decode %~f0 showwin.exe>nul
>
> cd /d "c:\app\editor\android\scrcpy"
> adb connect 192.168.0.2:5555

You have to do the cd before creating the exe

> @echo off

> cd /d "c:\app\editor\android\scrcpy"
> certutil -f -decode %~f0 showwin.exe>nul
>

> adb connect 192.168.0.2:5555

[Mr. Man-wai Chang]

On 22/4/2022 1:42 am, Andy Burnelli wrote:
> Is there a way to put a command window in the background like Linux does
> with the ampersand (so that you can kill the window but not the process)?
>
> The problem that I have is I run a lot of commands from the Run icon in my
> taskbar which bring up command windows to run scxripts but which leave
> the unnecessary command window sitting around (which can be iconified).
> <https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

Using a freeware like Trayit?

[Andy Burnelli]

Herbert Kleebauer wrote:

> I don't understand why you want to hide the console,

That worked like a charm!
<https://i.postimg.cc/CxXH6N2r/scrcpy13.jpg>

[sidenote]
At first there was an error window that popped up telling me that
the 32-bitness wasn't compatible with the 64-bitness of my computer;
but they stopped popping up. Also at first nothing happened, but
then later it worked consistently. I didn't document that fully.
[/sidenote]

I tried the series of tests below _before_ reading your two updates.
(So this response is only with respect to the article I'm replying to.)

My Use Model:
a. I click the Run box & type "mirror" & up comes _only_ the Android GUI.
b. Or, I doubleclick the showbat.lnk" shortcut pinned to the taskbar.
c. Up comes _only_ the Android GUI (there is no longer the scrcpy console!)

Woo hoo! You solved the problem set.
This technique should work for many similar issues.

> but this
> should do it (untested, I don't have a program which uses
> a GUI window and a console). Just start the below batch.

Test sequence #1:
a. I put the batch file into my C:\app\editor\android\scrcpy folder
b. I opened a command window in that folder & ran the executable
c. I also ran the command using the full path from the Run box
Run > C:\app\editor\android\scrcpy\showwin.bat

This popped up _only_ one window... the Android GUI!
<https://i.postimg.cc/nV6K0Cfn/scrcpy08.jpg> showwin.bat full path

> If it works, you can store showwin.exe somewhere in your
> PATH, so you don't have to create it temporarily every
> time you execute the batch. I post the usage of showwin.exe
> in a follow up.

I see there are two followups where the tests below are BEFORE
I read your useage followups as I was adding the efficiency steps.

Test sequence #2:
a. I put the batch file into my C:\app\editor\android\scrcpy folder
b. I added a Registry AppPaths key to enable "Run > mirror"
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\mirror.exe]
[@Default=C:\app\editor\android\scrcpy\showwin.bat]
<https://i.postimg.cc/66Gn2t2g/scrcpy09.jpg>
c. That sort of worked in that the GUI came up but so did the console.
<https://i.postimg.cc/htMdWG6z/scrcpy10.jpg>

Test sequence #3:
a. I put the batch file into my C:\app\editor\android\scrcpy folder
b. I added a shortcut whose TARGET was the showwin.bat command
NAME=C:\link\editor\android\scrcpy\showwin.lnk
TARGET=C:\app\editor\android\scrcpy\showwin.bat
<https://i.postimg.cc/7LWJhWxq/scrcpy11.jpg>
c. That worked perfectly in that the GUI came up but not the console!

Test sequence #4:
a. I put the batch file into my C:\app\editor\android\scrcpy folder
b. I added a shortcut whose TARGET was the showwin.bat command
NAME=C:\link\editor\android\scrcpy\showwin.lnk
TARGET=C:\app\editor\android\scrcpy\showwin.bat
<https://i.postimg.cc/7LWJhWxq/scrcpy11.jpg>
c. I modified that Registry AppPaths key that created "Run > mirror"
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\mirror.exe]
[@Default=C:\link\editor\android\scrcpy\showwin.lnk]
<https://i.postimg.cc/yYKNnHxD/scrcpy12.jpg>
d. That worked perfectly in that the GUI came up but not the console!
<https://i.postimg.cc/CxXH6N2r/scrcpy13.jpg>

Note that the last test would have worked the same had the
Windows registry "mirror.exe" key been set to the batch file
instead of to the shortcut "showwin.lnk" (either way works).

Woo hoo! No console. This is wonderful Windows magic indeed!
Thanks!
--
I didn't read your next two posts as I was working on this one
when I just noticed those two extra use-model posts came in.

[Andy Burnelli]

Herbert Kleebauer wrote:

> You have to do the cd before creating the exe

That's maybe why the one test of calling the showwin.bat
by its full path didn't work when run directly out of the Windows registry.
<https://i.postimg.cc/66Gn2t2g/scrcpy09.jpg>

I'll switch the order to bring up the CD earlier after I post this.

But that's OK because _all_ the other tests worked perfectly;
and, likely I could have put the full path in the batch file
and then that one test would also have worked (most likely).

> I don't understand why you want to hide the console,

I forgot to answer this perfectly valid question from you.
I apologize.

The reason is that the scrcpy console does nothing for me.
a. The console just gets in the way (as it has no way to interact with it).
b. The scrcpy console has to be manually minimized to get it out of the way.
c. And the scrcpy console uses up a precious slot on the taskbar.
d. Plus, it doesn't tell me anything that I want to know (if things work).

All of that is bad. None of that is good.
It's not horrible. But there's nothing good about any of that.

With the batch script, there is now no need to deal with the scrcpy console!
Thank you for helping me, and by way of extension, all the lurkers too.

BTW, here are the screenshots all together that were made for this thread.
<https://i.postimg.cc/CxXH6N2r/scrcpy13.jpg> No scrcpy console window!
<https://i.postimg.cc/yYKNnHxD/scrcpy12.jpg> REG test of showwin.lnk
<https://i.postimg.cc/7LWJhWxq/scrcpy11.jpg> Shortcut test of showwin.lnk
<https://i.postimg.cc/htMdWG6z/scrcpy10.jpg> The console came up :(
<https://i.postimg.cc/66Gn2t2g/scrcpy09.jpg> REG test of showwin.bat
<https://i.postimg.cc/nV6K0Cfn/scrcpy08.jpg> CMD test of showwin.bat
<https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg> Android mnt as drive letter
<https://i.postimg.cc/Sx1hgWmY/scrcpy06.jpg> Press two hardware buttons
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows

<https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

<https://i.postimg.cc/Vvrq0K0m/scrcpy03.jpg> The efficient setup explained

<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> An efficient program setup

<https://i.postimg.cc/N0G1TXcZ/scrcpy01.jpg> Mirror Android on any PC

In summary, with this set of solutions, anyone can instantly mirror
their Android phone on their PC (Windows, linux, or macOS) with a
shortcut (or Win+R command) without having to deal with the scrcpy
console window popping up and getting into the way of their nice setup!

Thanks for me and for the permanent Usenet record for others to benefit.
<http://groups.google.com/g/alt.msdos.bat>
<http://groups.google.com/g/alt.comp.microsoft.windows>

Specifically:
<https://groups.google.com/g/alt.msdos.batch/c/DmexCLwn_tM>
<https://groups.google.com/g/alt.comp.microsoft.windows/c/eMYBmpq2H50>

Note "alt.comp.os.windows-10" is poorly archived so it's not listed above.
--
Usenet is a world-wide team sport where purposefully helpful kind-hearted
adults help each other and learn by pooling our individual capabilities.

[Andy Burnelli]

Herbert Kleebauer wrote:

>> I post the usage of showwin.exe

Thanks for the showwin.{bat,exe} which ran the FOSS {adb,scrcpy} commands
omitting the scrcpy console (for efficiency and a clean user environment).
<https://i.postimg.cc/XqZsmVFM/scrcpy14.jpg> AppPath & shortcut TARGET

The only minor issue I had setting it up with shortcuts and AppPaths was
that you can't "directly" pin a batch file to the taskbar by default.

A. You can _not_ pin this shortcut to the taskbar

TARGET=C:\app\editor\android\scrcpy\showwin.bat

B. But you _can_ pin this shortcut to the taskbar
TARGET=%comspec% /c C:\app\editor\android\scrcpy\showwin.bat

Hence I added a "%comspec% /c% and _then_ I could pin the shortcut to the
batch file to the taskbar (and, once it's pinned, you can change it back).

Here is an illustration of the necessary change to pin the shortcut:
<https://i.postimg.cc/g2yNftw0/scrcpy15.jpg> Trick to pin batch shortcut

[Robert Roland]

On Sat, 23 Apr 2022 15:59:27 +0100, Andy Burnelli <sp...@nospam.com>
wrote:

>How can I tell the "scrcpy console" to be hidden?

I know VBScript and PowerShell can launch programs with the window
hidden. PowerShell's Start-Process cmdlet supports a "windowstyle"
parameter. This might be worth a try (single line):

powershell.exe -executionpolicy bypass -command "start-process
-filepath 'scrcpy' -argumentlist '--always-on-top
--tcpip=192.168.0.2:5555' -windowstyle 'hidden'"

If you want to hide or unhide a window "in-flight", I do not know of
any native way. There are ways to do it through the Windows API, and I
know PowerShell and VBScript can make API calls, but it is beyond my
abilities to write such a script.

If a third-party tool is acceptable, one of my favorites is AutoIt. It
is essentially a scripting language that has lots of built-in
functionality for manipulating the GUI. It can compile a script into a
standalone executable, which I really like. Take look here to get you
started:

https://www.autoitscript.com/autoit3/docs/functions/WinSetState.htm

Something like:

WinSetState ( "screencopy", "" , @SW_HIDE )

and

WinSetState ( "screencopy", "" , @SW_SHOW )
--
RoRo

[Andy Burnelli]

Robert Roland wrote:

>>How can I tell the "scrcpy console" to be hidden?
>
> I know VBScript and PowerShell can launch programs with the window
> hidden. PowerShell's Start-Process cmdlet supports a "windowstyle"
> parameter. This might be worth a try (single line):
>
> powershell.exe -executionpolicy bypass -command "start-process
> -filepath 'scrcpy' -argumentlist '--always-on-top
> --tcpip=192.168.0.2:5555' -windowstyle 'hidden'"

Thank you for that additional solution to the problem of hiding the console!

Woo hoo! That powershell Windows trick worked perfectly!
<https://i.postimg.cc/5NrK7jtg/scrcpy16.jpg> Powershell hide console trick

I always try all sensible purposefully helpful suggestions (if possible,
which is why I gravitate toward either native or FOSS solutions), where I
tried the following just now to see what it would do for me on my system:

Test sequence #1:
1. Run > cmd
2. ping 192.168.0.2 (just in case as my phone is set to not autoreconnect)
3. cd c:\app\editor\android\scrcpy (philosophically, I don't use $PATH)
4. adb kill-server (note that adb is, itself, it's own 'bridge' server)
5. adb connect 192.168.0.2:5555 (it's adb which does the TCP/IP connection)
6. powershell.exe -executionpolicy bypass -command "start-process -filepath 'scrcpy' -argumentlist '--always-on-top --tcpip=192.168.0.2:5555' -windowstyle 'hidden'"

Your powershell trick worked beautifully the first time!
<https://i.postimg.cc/5NrK7jtg/scrcpy16.jpg>

All I need now is to add the "&&" of the adb connection and the shortcuts
because all my customizations are always single-click one-command actions.

> If you want to hide or unhide a window "in-flight", I do not know of
> any native way. There are ways to do it through the Windows API, and I
> know PowerShell and VBScript can make API calls, but it is beyond my
> abilities to write such a script.

Thank you for that advice as if it's beyond your abilities, then it's out of
scope for mine since I'm not a coder. I'm a tweaker. I keep a clean system.

> If a third-party tool is acceptable, one of my favorites is AutoIt.

Funny you mention "AutoIt" since a _lot_ of the search results that came up
in my searches done before I had asked refer to solutions using that tool!
RUN > scrcpy

> It is essentially a scripting language that has lots of built-in
> functionality for manipulating the GUI. It can compile a script into a
> standalone executable, which I really like. Take look here to get you
> started:
>
> https://www.autoitscript.com/autoit3/docs/functions/WinSetState.htm
> Something like:
> WinSetState ( "screencopy", "" , @SW_HIDE )
> and
> WinSetState ( "screencopy", "" , @SW_SHOW )

Thanks for that kind-hearted purposefully helpful advice, where I, like you,
strive to provide the cross references necessary so that _others_ will
benefit simply by clicking on the links provided (as you kindly gave me).

To be sure, there are two automation apps I haven't adequately explored:
a. This helpful "autoit" PC automation suggestion of yours, and,
b. These "IFFT" & "Automate" Android free automation tools.
<https://i.postimg.cc/bvRXdbxg/scrcpy17.jpg> AutoIT & IFFT & Automate

For example:
*IFTTT - automation & workflow*, by IFTTT, Inc
free, ad free, requires GSF, rated 3.6, 5M+ installs
<https://play.google.com/store/apps/details?id=com.ifttt.ifttt>

*Automate* by LlamaLab
free, ad free, requires GSF, rated 4.4, 1M+ installs
<https://play.google.com/store/apps/details?id=com.llamalab.automate>

Note I gravitate to free tools because then the tutorials can be applied by
anyone since there is essentially no barrier to entry for others to test.

All three (AutoIT, IFFT & Automate) are on my "todo" learning-to-do list!
<https://i.postimg.cc/Y93b1z0n/scrcpy18.jpg> APKs at FOSS Google Play Store

Thanks!

[Lori Fairhead]

On Thursday, April 21, 2022 at 6:42:41 PM UTC+1, Andy Burnelli wrote:
> Is there a way to put a command window in the background like Linux does
> with the ampersand (so that you can kill the window but not the process)?
>
> The problem that I have is I run a lot of commands from the Run icon in my
> taskbar which bring up command windows to run scxripts but which leave
> the unnecessary command window sitting around (which can be iconified).

> <https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)
>

> As an example, for years I've been running commands from a shortcut target
> such as this target below which end up leaving an open command window in the
> taskbar after they call the process, which itself opens up its own window.
> %comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555

>
> That reliably pops up the Android screen on Windows over Wi-Fi but then I
> have absolutely no need for the command window to remain around as clutter.
>

> Is there a way to get rid of the command Window and not kill the process?
>

> In UNIX, I used to use the ampersand (&) to background the process.
> The I could easily close the window & the background process would remain.
>
> Does Windows have that concept of putting the command in the background so
> that the window that called it can be closed (but the process remains)?
>
> I have the same issue with openvpn windows where I don't need the extraneous
> running open command window cluttering up what otherwise should be a clean
> Windows user experience. I never enter another command in those windows.
>
> And yet, I can accidentally interfere with the open window because it's
> there and you can't get rid of it (other than to iconify it with the (-),
> but it's still there on the otherwise clean taskbar, just waiting to be
> opened by accident (and the icon looks like all other cmd window icons).
>
> For those reasons...

>
> Is there a way to background a Windows command (e.g., "&") and then we can
> safely _close_ that extraneous running command window to reduce clutter?

> --
> Usenet is where kind-hearted people daily gather to voluntarily help others.

Can you do it with START /B

Perhaps?

LF

[Herbert Kleebauer]

On 24.04.2022 07:48, Lori Fairhead wrote:

> Can you do it with START /B
>
> Perhaps?

If you provide such a simple solution, we look like idiots.
Welcome back!

[Kenny McCormack]

In article <k3v76h515r5cluk8h...@4ax.com>,
Robert Roland <fa...@ddress.no> wrote:
...

>In Windows, there are two types of programs: Console applications and
>pure GUI applications.
>
>It is not always easy to spot which is which, because a console
>application can also create graphical windows.

And note, just for completeness, that a "Pure GUI application" can create a
console window too. Using AllocConsole().

Or even "AttachConsole()".


--
"We are in the beginning of a mass extinction, and all you can talk
about is money and fairy tales of eternal economic growth."

- Greta Thunberg -

[Andy Burnelli]

Herbert Kleebauer wrote:

>> Thank you for that additional solution to the problem of hiding the console!
>

> Did you read the simple solution given in alt.msdos.batch: START /B

It is pure genius, I agree... (and Lord knows, I _love_ simplicity!);
but for the life of me, I haven't gotten the shortcut syntax correct yet.
<https://i.postimg.cc/3R6nTz7s/scrcpy19.jpg> Start /b TARGET fails :(
<https://i.postimg.cc/Y9jbTtcN/scrcpy20.jpg> Start /b as a CMD works! :)

TEST #1 (shortcut target):
a. For whatever reason, when I added the "start /B scrcpy" to the TARGET,
b. Doubleclicking that shortcut opened the Android GUI as desired,
c. But it _also_ left an adb window in its wake.

TARGET=%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start /B scrcpy --always-on-top --tcpip=192.168.0.2:5555
STARTIN=c:\app\editor\android\scrcpy

Yet, if I run that exact line in the command window, it works just fine!

TEST #2 (command line):
a. The command runs inside the command window,
b. The Android GUI opens up,
c. And then the command window goes away.

I've been trying various syntax efforts (e.g., the aforementioned trailing
"&cls%exit" stuff), but I haven't figured out yet why the same command line
above pasted into the command window works differently than that same
command line above when it's pasted into a shortcut TARGET line.

Makes no sense to me why the shortcut isn't working.
And yet, the _same_ line pasted into a command window works as expected.
--
PS: I'll monitor alt.msdos.batch moving forward until this is resolved.

[Andy Burnelli]

Kenny McCormack wrote:

> And note, just for completeness, that a "Pure GUI application" can create a
> console window too. Using AllocConsole().

To the point of hiding the console for the better-written programs, I tested
out the "free" Vysor crippleware which has a huge advantage over scrcpy in
that it can work remotely over the Internet for both Android & iOS on all
the common consumer desktop platforms (namely Windows, Linux & macOS).
<https://www.vysor.io/> "A window to your Phone"
"Vysor puts your iOS or Android on your desktop.

Notice Vysor mirrors Android much like scrcpy did, with an added console:
<https://i.postimg.cc/QNwjsCDM/vysor01.jpg> Vysor Android/iOS PC mirroring

Yet, unlike scrcpy in the native setup, the Vysor console can be killed:
<https://i.postimg.cc/V6TPYG3h/vysor02.jpg> Vysor console closes gracefully
--
Usenet is where kind-hearted well educated people gather to exchange ideas.

[Andy Burnelli]

While testing other "free" screen mirroring solutions, I tried out the
"Vysor" crippleware which does at least what scrcpy FOSS software does.

<https://www.vysor.io/> "A window to your Phone"
"Vysor puts your iOS or Android on your desktop.

Use apps, play games, control your iOS or Android.
A desktop or web app, compatible with all operating systems.
Use your Keyboard. Point, click, scroll. Your mouse works too.
Share your device, across the office, or across the globe.
Screen and ADB access to remote devices. Simple as sending a link."

I was pleasantly surprised that the Vysor console easily can be closed.

<https://i.postimg.cc/QNwjsCDM/vysor01.jpg> Vysor Android/iOS PC mirroring

Without adversely affecting the existing Android (or iOS) mirroring windows:

<https://i.postimg.cc/V6TPYG3h/vysor02.jpg> Vysor console closes gracefully

From that (and a few other indications), I can report back after only an
hour of testing Vysor, that it appears to be more "consumer focused" than
scrcpy is (where scrcpy is more focused on the developer or expert user).

Vysor apparently works with all phones and all desktops:
<https://youtu.be/qAHTini67GA>
Name: Vysor-win-4.1.77.exe
Size: 115651304 bytes (110 MiB)
SHA256: 0984A30C0BC1A76376D675C92CEC47725E16A9A6A5816A39FB8C7124BCA50DC7

The free version can do these two things which we've been discussing:
a. Mirror and Control iOS/Android
b. Screenshots

Their payware version has more functionality (which we had in scrcpy):
<https://www.vysor.io/#pricing>
High Quality Mirroring
Fullscreen Mode
Go Wireless
Vysor Share
Drag and Drop Files
--
Usenet is a huge community of kind hearted people who help each other learn.

[Andy Burnelli]

While the problem has been solved using multiple methods, and while we already
learned how to additionally (theoretically anyway) connect both iOS & Android to
Windows, we always strive to learn from everyone in every Usenet post, by design.

Since you sugegsted "Trayit", it behooves me to learn what the heck it is.
<https://www.google.com/search?q=windows+software+what+is+trayit>

First result:
*What is TrayIt?*
<https://quick-adviser.com/what-is-trayit/>
"TrayIt! is a small free utility that allows you to minimize any program
to the Windows tray rather than the Windows taskbar. TrayIt... can set
any window or application to minimize to the task tray and still
continue to run."

This sounds useful! Thanks for your kind-hearted purposefully helpful advice!

As often occurs, a simple search also found other programs similar to TrayIt!
*Using RBtray to Quickly Minimize Almost Any Window to Tray*
<https://www.online-tech-tips.com/windows-10/how-to-minimize-a-windows-program-to-the-system-tray/>

Thanks for teaching me (and others) on Usenet how to fish!
<http://rbtray.sourceforge.net/>

As with many freeware implementations, the sheisters abound, so it takes a
while to pluck out the canonical trusted site among the many others...
<https://www.teamcti.com/trayit/trayit.htm>

Given I already have multiple solutions, I will test this out when I get
the chance because if you took the time to suggest it, I will test it.

Here are the files I downloaded for testing TrayIt! & RBtray:
Name: trayit_4_6_5_5.zip
Size: 335253 bytes (327 KiB)
SHA256: 5B086BF87AFF1DC4F9D371A20CD929DBE2EAA156F43D4B40ECB9170F1868618E

Directory of C:\archive\os\taskbar\trayit\trayit_4_6_5_5\trayit_4_6_5_5
04/29/2022 04:40 PM <DIR> .
04/29/2022 04:40 PM <DIR> ..
04/29/2022 04:40 PM <DIR> lang
04/29/2022 04:40 PM 2,914 readme.txt
04/29/2022 04:40 PM 1,332 translation.txt
04/29/2022 04:40 PM 204,800 TrayIt!.exe
04/29/2022 04:40 PM 3,479 TrayIt!.std
04/29/2022 04:40 PM 7,680 trayit4!.dll
5 File(s) 220,205 bytes
3 Dir(s) 68,597,497,856 bytes free
Name: TrayIt!.exe
Size: 204800 bytes (200 KiB)
SHA256: 5F5C2DDC5531AD796ADD91D7882FA4AFB437468B5F37454FA4BB3729E93E7668

Name: TrayIt!.exe
Size: 204800 bytes (200 KiB)
SHA256: 5F5C2DDC5531AD796ADD91D7882FA4AFB437468B5F37454FA4BB3729E93E7668

Name: trayit4!.dll
Size: 7680 bytes (7 KiB)
SHA256: 5366F447CE37EE206E06A6C50642279B8BE56D337D7225D9B1AD7FB410D9B8E3

And here are the files I downloaded for testing the FOSS RBTray software:
http://rbtray.sourceforge.net/
https://sourceforge.net/projects/rbtray/files/rbtray/4.3/RBTray-4_3.zip/download
https://versaweb.dl.sourceforge.net/project/rbtray/rbtray/4.3/RBTray-4_3.zip

Name: RBTray-4_3.zip
Size: 93156 bytes (90 KiB)
SHA256: 4FCC384437F753861D66B5BD58D607092AABE1DE8CC8392271A8872B86133EC2

Directory of C:\archive\os\taskbar\trayit\RBTray-4_3\64bit
04/29/2022 04:44 PM <DIR> .
04/29/2022 04:44 PM <DIR> ..
04/29/2022 04:44 PM 38,912 RBHook.dll
04/29/2022 04:44 PM 45,568 RBTray.exe
2 File(s) 84,480 bytes
2 Dir(s) 68,615,860,224 bytes free
Name: RBTray.exe
Size: 45568 bytes (44 KiB)
SHA256: 2990B379EAB81753EDE04D017BE30AD6381835C0531BE4AA66C56D4E91122417

Name: RBHook.dll
Size: 38912 bytes (38 KiB)
SHA256: B181FB71DEAC6BEEAC564019815DB636AACF71291A1DDF20FD14E23246AE637E
--
Usenet is where well-educated intelligent friendly people daily gather to
discuss topics of interest and to help learn from each other every day.

[Andy Burnelli]

Andy Burnelli wrote:

>> I don't understand why you want to hide the console,
>
> That worked like a charm!
> <https://i.postimg.cc/CxXH6N2r/scrcpy13.jpg>

UPDATE:
(Since that's part of learning and key to paying back for the kind help!)
This morning I found out a rather useful feature of the (Vysor) console!
<https://i.postimg.cc/c4Wq5x9j/scrcpy22.jpg> Vysor IP address option

I've been using _both_ the scrcpy Android mirroring & then hiding of the
console along with Vysor (which is designed to easily hide the console)
when I suddenly realized there is at least one very good _reason_ you might
want the [Vysor] console (as illustrated in this case below from today).

I was setting up my spare iOS devices as as a remote wildlife camera
outside at the barn but since the Apple Mobile Device Software won't
install, I am temporarily using my Android instead of my spare iPad.

The result of the distance was connecting to a _different_ access point
(of which I have many sprinkled about the house, the barn, the pool, etc.)
<https://i.postimg.cc/XJChDCPr/spare-access-points.jpg> My home Wi-Fi APs

That caused the phone IP address to change from what it has been all along.
And yet, the scrcpy scripts I've been using have the IP address hard coded.

The result was that my scrcpy scripts (which worked wonderfully with a
static IP address) failed to work - but the Vysor GUI has an IP option!
<https://i.postimg.cc/c4Wq5x9j/scrcpy22.jpg> Vysor IP address option

The point here is that it's nice, to sometimes have that (Vysor) console
GUI (at least until everything is up and running with the right IP address)
because it allows me to choose the IP address of the device to mirror.

BTW, in terms of always striving to not only solve the problem, and not
only to help others solve the problem, but to also add increased value, I
will test the suggestion from Mr. Man-wai Chang to try these tray utils:
<https://groups.google.com/g/alt.msdos.batch/c/DmexCLwn_tM/m/UT1MXgrsAAAJ>
--
On Usenet, intelligent purposefully helpful kind-hearted volunteers staff
the helpdesk which I will then strive to increase value by way of payback.

[Andy Burnelli]

UPDATE:

You _never_ need USB cable ever again!

This is a PSA update to this thread which was solved a while ago,
but where I've been using it daily and have a couple of improvements.
<https://i.postimg.cc/k5gv0yw8/vysor34.jpg> Apple iOS & Android mirroring

The first improvement is huge, which is that Android 12 (maybe Android 11?)
has the hidden Developer option for "Wireless debugging" which eliminates
completely the need for a USB cable to connect to Windows.
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Debugging

You can keep the phone in your pocket or on your desk, or better yet,
on your wired or wireless charger, and you'll _never_ need that USB
cable ever again to interface with Windows in any way you'd like to.

<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows

That is, without ever needing USB...
1. You can mirror Android/iOS over the random-assigned port
<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> iOS & Android PC mirroring
2. And you can mount the Android phone as a drive letter
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Android as a drive letter
3. WITHOUT needing to run any adb-pairing steps
<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

The tools I've been using for a few months to mirror over Wi-Fi are:
a. Vysor (I use this daily, as scrcpy is flakier than is Vysor for me)
b. Scrcpy (I use this when I need better resolution than Vysor gives me)
<https://i.postimg.cc/rmBHmvtV/adb18.jpg> Windows adb vysor & scrcpy

And the tools I use for mounting Android as a drive letter are:
a. WebDAV (I use this daily to mount the _entire_ phone as two drives
b. FTPUse (I don't use it though as it's flakier than WebDAV for me)
<https://www.ferrobackup.com/map-ftp-as-disk.html>

Notice a few details which take time to figure out:
A. Android 12 has a secret hidden Wireless debugging pulldown tile
<https://i.postimg.cc/qRhkhTwV/adb21.jpg> Hidden Wireless-debugging tile
B. Using that tile, Vysor will AUTOMATICALLY figure out the random port!
(Phone) Turn on Wi-Fi
(Phone) Connect to a Wi-Fi AP
(Phone) Turn 'Developer options' 'Wireless debugging = on'
(Phone) Tap "Allow" if it asks to
"Allow wireless debugging on this network?"
Which will be for a specific SSID & (usually random) BSSID.
(PC) C:\> vysor.exe (and then press on the red arrow)
That connects you to adb over the random port on Wi-Fi
without needing to run the new Android 12 adb pairing commands!
<https://i.postimg.cc/ZK9B82gP/adb15.jpg> adb pair [IP][Port] [code]
C. This Windows command tells you which random port adb is using:
C:\> netstat -ano -p tcp | findstr "192.168.0.2"
D. That random port is IMPORTANT to put in the scrcpy batch file
that Herbert kindly wrote which enables the console to be killed.
(see batch file in the sig)
E. Of course, you can get that random port from the phone itself
(but Vysor automatically figures it out - but scrcpy does not
figure out that randomly assigned port, as far as I know).
F: Vysor will also automatically install Vysor on Android temporarily!
<https://i.postimg.cc/Njg6Xx3V/vysor33.jpg> Preparing Vysor on device
G: If the adb connection gets confused (it sometimes happens):
(PC) C:\> adb kill-server
(PC) C:\> vysor.exe (and then press on the red arrow after about 30 seconds)
Note Vysor is magical in figuring out what port adb is using!
H. The free vysor.exe is lower resolution than the free scrcpy.exe
<https://i.postimg.cc/CLyK8z9v/adb20.jpg> Both vysor & scrcpy use adb
I. You need _two_ WebDAV servers to mount the internal & external sdcards
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Android as a drive letter
sdcard0 (Using "WebDav Server" as the free WebDAV server on Android)
C:\> net use Y: \\192.168.0.2@8080\DavWWWRoot /USER:foo bar
*WebDAV Server - BestDAV" by ZQ Software
Free, no ads, no GSF, rated 3.4, 100+ reviews, 10K+ downloads
<https://play.google.com/store/apps/details?id=com.zq.webdav.app_free>
Pro: Works well, no ads, no gsf, autostarts upon reboot
Con: Slightly harder to set up as it requires full paths

sdcard1 (Using "Olive Tree" as the free WebDAV server on Android)
C:\> net use Z: \\192.168.0.2@8081\DavWWWRoot /USER:foo bar
*WebDAV Server* by The Olive Tree
Free, has ads, requires GSF, rated 3.5, 800+ reviews, 100K+ downloads
<https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>
Pro: Works well, slightly easier to set up
Con: ads, gsf, and won't autostart on reboot

In summary, above are some hints as a kind-hearted PSA to help all
of those who helped everyone write the batch code in this thread!

I always strive to pay back for all the help that I received from you!
--
@echo off

cd /d "c:\app\editor\android\scrcpy"

certutil -f -decode %~f0 showwin.exe>nul

REM Port 5555 was needed when you established adb connections over USB
REM And then you disconnected the USB cable to subsequently work on Wi-Fi
REM But as of Android 11 or 12, you can establish the connection over Wi-Fi
REM But that "Developer option" "Wireless debugging" port is random!
REM So you have to get it on Android or on Windows to know what it is

REM You can get the current assigned port from the following command
REM c:\> netstat -ano -p tcp | findstr "192.168.1.10"

REM adb connect 192.168.1.10:5555
adb connect 192.168.1.10:45299

:: now we hide console window
showwin.exe 0

REM scrcpy --always-on-top --tcpip=192.168.1.10:5555
scrcpy --always-on-top --tcpip=192.168.1.10:45299

:: after scrcpy is closed we show console window again
showwin.exe 5

[Kenny McCormack]

In article <tb0osl$1tl1$1...@gioia.aioe.org>,

Andy Burnelli <sp...@nospam.com> wrote:
>UPDATE:
>
>You _never_ need USB cable ever again!

I fail to see how the Subject line:

Is there a way to put a command window in the background like Linux

does (so that you can kill it)?

has anything whatsoever to do with USB cables.

--
http://www.rollingstone.com/politics/news/the-10-dumbest-things-ever-said-about-global-warming-20130619

[Andy Burnelli]

Kenny McCormack wrote:

> I fail to see how the Subject line:
>
> Is there a way to put a command window in the background like Linux
> does (so that you can kill it)?
>
> has anything whatsoever to do with USB cables.

I'll answer your question, in detail, with an easily understood real-life
example that highlights why, at the beginning of a quest, you can't always
foresee the solution well enough to ask specifically, at the beginning, for
the exact solution you'll choose as the best solution to the problem set.

I live in mountains where they don't want people to live, so they have
40-acre zoning (meaning you can only put up one house on 79 acres), and we
don't even have Internet on the power poles (everything is WISP), nor any
public utilities other than power & phone (which few people use nowadays).

As a result of living in the boonies, I ensure my cellphone has the
necessary tools to do what I need it to do, without the Internet.

One example of a set of tools that must work without the Internet are the
common backcountry tools that you probably are familiar with for hiking.

Yet the problem for me is a bit different than for most people since most
people stay on the trails, yet I eschew trails like I eschew Google/Apple.

The fact is I hike.
Off trail.
A lot.

Alone.

In the mountains.
Rough mountains.
And I do it by point-to-point topographical "dead reckoning" orienteering.

OK. So now you know the problem set, where my quest, let's say, is to find
a suitable set of free ad free gsf free tools that enable efficient hiking.

What's my question?
Well, for one, there are tools you can easily _predict_ you'll need, right?

Did you ever use the tools you had on your phone to get to a point in the
mountains that is only, oh, say, a short distance as the crow flies & you
have a pretty good idea of what tools you'll need to get there....such as:
a. A compass & location reader (that doesn't rely in the Internet)
b. An altimeter (that doesn't rely in the Internet)
c. A wayfinder (that doesn't rely in the Internet)
d. A track logger with photos (that doesn't rely in the Internet)
e. A custom topographical geoPDF (that doesn't rely in the Internet)
f. An app that handles any custom topographical geoPDF (no Internet)

For example, below are _excellent_ free ad free tools for each of those
tasks where _none_ of that freeware reports your privacy or uses cellular.
a. <https://gitlab.com/mvglasow/satstat>
b. <https://play.google.com/store/apps/details?id=com.mirkix.barometer>
c. <https://play.google.com/store/apps/details?id=com.keuwl.gpswaypoints>
d. <https://f-droid.org/en/packages/de.dennisguse.opentracks/>
e. <https://www.usgs.gov/programs/national-geospatial-program/topographic-maps>
f. <https://play.google.com/store/apps/details?id=com.Avenza>

But wait.... while on the hike, you realized those plans didn't survive
contact in that you didn't realize you also may need more tools than that.
g. A custom geopdf application that handles more than 3 USGS quadrangles
h. A quick tap-to-save getback application when exploring around obstacles
i. An emergency sms location reporter (in case you break a leg on a cliff)
j. A cellular signal strength monitor (to test for emergency communication)

Needing more solutions, you ask on the Usenet for a cellular signal
strength monitor and, at first, you get the answer to use Cellular-Z.

But wait, you asked on Usenet for a cellular signal monitor but what you
asked for was the wrong thing because you don't have the luxury of looking
at a screen constantly, so what you really should have asked for, which
comes out in the thread, is for a signal strength "pinger" that gives an
audible alarm when you lose cellular signal (it works without looking).
k. A cellular-signal pinger that pings while the phone is in your pocket

But when you try that pinger, you realize it doesn't tell you anything
about cellular _data_ signal, which is a _different_ tool altogether:
l. A cellular _data_ connection notification app

The point is that you don't know what tools you'll need at the _start_ of
the quest... where solutions you'll need may morph over time to add...
g. <https://play.google.com/store/apps/details?id=ca.abbro.androidmap>
h. <https://github.com/ruleant/getback_gps>
i. <https://play.google.com/store/apps/details?id=ru.perm.trubnikov.gps2sms>
j. <https://play.google.com/store/apps/details?id=make.more.r2d2.cellular_z>
k. <https://play.google.com/store/apps/details?id=com.simple.axanor.simpleconnectivitymonitor>
l. <https://play.google.com/store/apps/details?id=com.gordienoye.cellulardatanotifier>

Notice at the start you didn't even realize what you really needed wasn't a
graphical cellular signal strength monitor per se, but audible apps to let
you know while the phone is in your pocket when you had no signal strength
for phone calls and/or for SMS/MMS texts.

What you are attempting to do is hold me to that longer list, based solely
on experience, when I planned ahead as best I could but I didn't know then
what I know now as to the final set of solutions which solve the problem.

For example, I know I want to _draw_ a GPX track by hand, but I don't know
of _any_ smartphone freeware that does that, so I resort to online freeware
such as Caltopo online mapping tools which allow you to draw a track on an
accurate topographic map and then export that track to use on your phone.
<https://caltopo.com/map.html#ll=38.80547,-98.39355&z=5&b=mbt>

But then I might find out that I don't have a program on the smartphone
that will give _directions_ based on that imported GPX track (e.g., it
might alert you "Go west for 100 feet to get back onto the desired track").

What you ask for in a Usenet thread is based only on what you can plan for.

Even after all that planning and adjusting and improving the solution, you
may find that you also need a fake gps spoofer, perhaps in order to more
easily tell specific apps any desired given location without having to
laboriously _type_ latitude/longitude coordinates in, such as this app:
<https://play.google.com/store/apps/details?id=com.lexa.fakegps>

But then you find out that you need to set Android Developer options
"Mock location app" to that app, which entails deeper knowledge of the
inner workings of Android to get the app to work within your hiking plan.
<https://www.virtuallocation.com/fake-location/allow-mock-locations.html>

In summary, when you are solving problems that nobody else has ever solved
(which we did in this thread), you don't know at the start of the quest
what tools you will end up as your final efficient working solution.

When you _do_ find the tools though, it's basic Internet courtesy to give
back to the team added value by way of what solution worked best for you.
--
This response is a well-researched answer to Kenny McCormack's question,
because Kenny seems to think we should always know the solution we are
going to end up with _before_ we ask the question on this Usenet group.

[Kerr-Mudd, John]

On Mon, 18 Jul 2022 06:46:43 +0100
Andy Burnelli <sp...@nospam.com> wrote:

> Kenny McCormack wrote:
>
> > I fail to see how the Subject line:
> >
> > Is there a way to put a command window in the background like Linux
> > does (so that you can kill it)?
> >
> > has anything whatsoever to do with USB cables.
>
> I'll answer your question, in detail, with an easily understood real-life

[Massive snipping]

> In summary, when you are solving problems that nobody else has ever solved
> (which we did in this thread), you don't know at the start of the quest
> what tools you will end up as your final efficient working solution.
>
> When you _do_ find the tools though, it's basic Internet courtesy to give
> back to the team added value by way of what solution worked best for you.
> --
> This response is a well-researched answer to Kenny McCormack's question,
> because Kenny seems to think we should always know the solution we are
> going to end up with _before_ we ask the question on this Usenet group.

That's a lot of words. I guess the actual answer is that it doesn't have
anything to do with the actual wording of the Original Question, and is
now well off-topic for amb (and pretty much so for windows too, as it seems
the topic is now "how do I access (some poweruser mode) in Android"

Glad you got to where you wanted to, though.

--
Bah, and indeed Humbug.

[Andy Burnelli]

Kerr-Mudd, John wrote:

> Glad you got to where you wanted to, though.

Sigh. The effort spent on providing an analogy failed. :(
So I'll have to simply spell out what is obvious to all who understood.

This is what happened...

1. *I asked to put a process in the background so I could kill it.*
2. *The team came up with a Windows batch method that killed the console.*
3. *That method worked fine with USB cables as the port was fixed at 5555.*

However...
4. *Unfortunately, the Wi-Fi method _requires_ prior knowledge of the*
*constantly changing Android Wireless debugging port assignment.*

OK... now _this_ is the important point for Windows batch processing!
a. *So, for USB, the batch file works fine (as the port is static!).*
b. *But for Wi-Fi, the batch file random port has to be changed daily.*

Do the basic details of the problem set sink in yet?

Clearly, my recent update gave _how_ to obtain that IP address and port
information (whether or not Curmudgeon or McCormick understood that fact).

What _both_ of those trolls clearly didn't do was _read_ the thread.
Of, if they did, they didn't comprehend a word that was said in the thread.

They both posted without even thinking about what the thread was about.
Even as they complained that they didn't understand what it was about.

It's not my fault they don't understand the progress we made in this
thread, nor is it my fault that they don't understand that the port is
static for USB but dynamic for Wi-Fi (which is a big deal in a script!).

Nonetheless, that's water under the bridge now that I've EXPLAINED to both
of them what they failed to grasp (first in analogy, second in actuality).

Moving forward...

BTW, what I'm working on now, to _improve_ that process, is determining
_how_ Vysor.exe figures out the Android port but why Scrcpy.exe does not.

That's critical to put in the batch script:
_Q: How does Vysor know the adb port but scrcpy does not know it?_

If I can figure _that_ out, then there is no longer a need to add the
explicit IP address and port to the Wi-Fi version of the scrcpy batch file
originally written by Herbert (note that the USB version doesn't have that
problem because the USB version of Herbert's scrcpy batch script only needs
the port 5555 in all cases - but the Wi-Fi version uses random ports!).

If the analogy failed, did the direct 4-step explanation sink in yet?
--
HINT: See the actual resulting batch file added in the prior sig,
which was posted to be provide in comments why daily modification is needed
when on Wi-Fi even as Herbert's batch file worked fine being static on USB.

[Andy Burnelli]

Kerr-Mudd, John wrote:

> That's a lot of words. I guess the actual answer is that it doesn't have
> anything to do with the actual wording of the Original Question, and is
> now well off-topic for amb (and pretty much so for windows too, as it seems
> the topic is now "how do I access (some poweruser mode) in Android"

Woo hoo!

*IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'!
<https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround

It took me days (elapsed time) to figure out this latest workaround
to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.

IMHO, *it's a crime that Windows totally lacks 'Ctrl+Z,bg' functionality.*
All this effort would NOT be needed if Windows simply had 'Ctrl+Z,bg'.

Yet, the final 'Ctrl+Z,bg' solution turns out to be incredibly simple.
If you know a few of the tricks, that is, to replace 'Ctrl+Z,bg'.

This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.
1. Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.
2. And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*

This new 'Ctrl+Z,bg' workaround can now be added to the existing
'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.

The USB 'Ctrl+Z,bg' workaround, which expects a static port, only need to
have added a new 'Ctrl+Z,bg' variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

[Andy Burnelli]

Woo hoo!

*IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'

<https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround

It took me days (elapsed time) to figure out this latest workaround
to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.

Yet, the final solution turns out to be incredibly simple.
If you know a few of the tricks, that is.

This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.

Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.

And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*

This new 'Ctrl+Z,bg' workaround can now be added to the existing
'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.

It need only be a variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

As you may recall, the 'Ctrl+Z,bg' workaround script Herbert kindly
proposed was to solve the lack of 'Ctrl+Z,bg' in Windows given
conditions of an initial USB connection.

That initial USB connection only needed a _static_ port address.

So the previous 'Ctrl+Z,bg' workaround script worked fine as that
previous 'Ctrl+Z,bg' workaround script didn't need to query Android
for the port address.

The problem that arose in Android 11+ is the addition of Wireless
debugging which necessitated the 'Ctrl-Z,bg' workaround batch script
now knowing, a priori, what that randomly assigned wireless debugging
IP address is.

But how?
Specifically, how do you query Android WITHOUT first establishing
a connection to it (where that connection _requires_ the random port!).

Seemingly that's impossible, right?
Ah, but it's not impossible.

It took me a few days (elapsed time) to figure out how to query Android
from Windows to _obtain_, a priori, that randomly assigned IP address!

Luckily I found two Windows commands which will obtain that random port:
C:\> netstat -ano -p tcp | findstr "192.168.1.10"
C:\> adb mdns services

Below is a log file reproducing the steps in only a minute or two.

<https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround

----------------------
Log file for this image: <https://i.postimg.cc/zfLp8b2v/adb22.jpg>
C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
* daemon not running; starting now at tcp:5037
* daemon started successfully
adb.exe: no devices/emulators found

C:\app\editor\android\scrcpy>adb devices
List of devices attached


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services


C:\app\editor\android\scrcpy>On Android, turn wi-fi on & connect to the LAN (wait a minute or two)

C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
adb.exe: no devices/emulators found

C:\app\editor\android\scrcpy>adb devices
List of devices attached


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services


C:\app\editor\android\scrcpy>Now turn on Developer options, Wireless debugging & accept the "Allow" (wait 2 min)

C:\app\editor\android\scrcpy>Note that the phone knows the address & port of 192.168.1.10:36999 (not the PC)

C:\app\editor\android\scrcpy>When the phone beeps with "Wireless debugging connected", you're ready

C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"
TCP 192.168.1.27:49765 192.168.1.10:36999 ESTABLISHED 3208

C:\app\editor\android\scrcpy>Bingo! The PC now knows the Wireless debugging IP address & random assigned port!

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
192.168.1.10

C:\app\editor\android\scrcpy>Windows adb knows only the IP address (but not the randomly assigned wireless port) :(

C:\app\editor\android\scrcpy>adb devices
List of devices attached
adb-ABCEFGHIJKL-123456._adb-tls-connect._tcp. device


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services
adb-ABCEFGHIJKL-123456._adb-tls-connect._tcp. 192.168.1.10:36999


C:\app\editor\android\scrcpy>Ah. Nice. So Windows adb DOES know the IP address & randomly assigned wireless debug port

C:\app\editor\android\scrcpy>scrcpy.exe
scrcpy 1.24 <https://github.com/Genymobile/scrcpy>
C:\app\editor\android\scrcpy\scrcpy-server: 1 file pushed, 0 skipped. 0.8 MB/s (41159 bytes in 0.051s)
[server] INFO: Device: samsung SM-A326U (Android 12)
INFO: Renderer: direct3d
INFO: Initial texture: 720x1600

At this point you would die for a "control-Z bg" command sequence.
If that 'Ctrl+Z,bg' existed on Windows, this thread wouldn't be needed.
But alas, Windows completely lacks such a 'Ctrl+Z,bg' luxury.
Hence the need for a 'Ctrl+Z,bg' workaround batch script.

If 'Ctrl+Z,bg' existed on Windows, we would never have this problem
of querying Android from Windows to obtain the Wireless-debugging
port random assignment (because scrcpy console does NOT need it!).

But if we want to eliminate the scrcpy console, then we need to
find a workaround to the fact that Windows completely lacks a
basic 'Ctrl+Z,bg' functionality. <=== this is the problem!

Since 'Ctrl+Z,bg' does NOT exist on the PC, we need to tell
the 'Ctrl+Z,bg' workaround batch script what that randomly assigned
port is set to on Android WITHOUT looking at Android.

The 'Ctrl+Z,bg' workaround script must figure it out on its own!
Hence you must figure out the random port assignment from the PC.

Notice scrcpy with the console does NOT need to know this port.
It figures it out on its own.

So it's only the 'Ctrl+Z,bg' workaround script that NEEDS this port.
All we need now is to ADD that new 'Ctrl+Z,bg' variable to the script!

In summary, the old USB 'Ctrl+Z,bg' workaround, which expects a static port, only needs to have added a new 'Ctrl+Z,bg' variable,
e.g., %GET-RANDOM-PORT-ASSIGNMENT%

[Andy Burnelli]

Andy Burnelli wrote:

> Woo hoo!
>
> *IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'!
> <https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround
>
> It took me days (elapsed time) to figure out this latest workaround
> to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.
>
> IMHO, *it's a crime that Windows totally lacks 'Ctrl+Z,bg' functionality.*
> All this effort would NOT be needed if Windows simply had 'Ctrl+Z,bg'.
>
> Yet, the final 'Ctrl+Z,bg' solution turns out to be incredibly simple.
> If you know a few of the tricks, that is, to replace 'Ctrl+Z,bg'.
>
> This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.
> 1. Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.
> 2. And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*
>
> This new 'Ctrl+Z,bg' workaround can now be added to the existing
> 'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.
>
> The USB 'Ctrl+Z,bg' workaround, which expects a static port, only need to
> have added a new 'Ctrl+Z,bg' variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

This quest started solely because there is no "control+Z" in Windows.

However, the result is we have a finely tuned working system without it!
a. I always give back to the team for helping me solve all the problems,
b. So here are minor updates based on daily use of Herbert's showwin.bat

*UPDATE #1:*

There is a workaround to the fact the random port address must be known:
<https://i.postimg.cc/tgvzsMRm/scrcpy25.jpg> Connect over Wi-Fi sans USB

While scrcpy.exe doesn't need any specifics once a connection is
established, there are times when you have _multiple_ devices connected.
<https://i.postimg.cc/zDCTY9NS/adb28.jpg> multiple adb connections

More so, there are two different ways to pair in the first place!
<https://i.postimg.cc/R0BXTMCy/adb29.jpg> multiple pairing connections

Then you _must_ specify _which_ device (even if they're all the same!)

It turns out scrcpy can use the "-s 192.168.0.2" or "-s SERIAL.tcp"
or "-s SERIAL" or even "--tcpip=[IP]:[PORT]" each of which makes it
easier to connect over Wi-Fi (sans USB cable) from Windows using
Herbert's excellent showwin.bat script (once you've established pairing).

<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

The scrcpy.exe can sometimes use the short form of the Android serial.
<https://i.postimg.cc/9MSg3sjj/adb33.jpg> Long and short serial formats

And scrcpy.exe can sometimes use the IP address & random port of course:
C:\> scrcpy.exe --tcpip=192.168.0.2:41269
<https://i.postimg.cc/L4bDbk6z/adb27.jpg> scrcpy --tcpip=[IP]:[PORT]

*UPDATE #2:*
There is no workaround yet to the original need for the random port
(whether you connect via "connect" or the encrypted "pair" command).

Once you've connected, scrcpy.exe does not need to know the IP address
or port or serial number or tcp address & port _if_ there one device.

<https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

But most of the time you have multiple devices connected via adb.
And then the scrcpy.exe inside Herbert's script needs to know which one.
<https://i.postimg.cc/tgvzsMRm/scrcpy25.jpg> Connect over Wi-Fi sans USB

*UPDATE #3:*
Also note that scrcpy has _better PC resolution_ than does free vysor
<https://i.postimg.cc/xdSMtBkn/vysor36.jpg> scrcpy vs Vysor resolution

*UPDATE #4:*
Note that Vysor works with my iOS devices (but with less functionality)

<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> iOS & Android PC mirroring

*UPDATE #5:*
Android 12 has mac randomization per connection - which is working fine!
<https://i.postimg.cc/nchSVcmS/vysor30.jpg> Static/Reserved IP address

*UPDATE #6:*
For weeks (elapsed time) I've tried various methods to get around pairing,
but so far, none of them works as well as _looking_ at the random port.

<https://i.postimg.cc/SRRXtvKh/adb16.jpg> Android 12 Wireless Pairing

*UPDATE #7:*
All Windows debugging commands work only _after_ you've already paired!
<https://i.postimg.cc/DZV4tcYM/adb30.jpg> Windows pairing debuggers

*UPDATE #8:*
The separate issue of accessing all of Android as a Windows drive has
been working flawlessly with the simple "net use" commands outside of adb.
<https://i.postimg.cc/9FJMKYch/scrcpy21.jpg> Windows Drive: === Android

C:\> net use Z: \\192.168.0.2@8080\DavWWWRoot /USER:foo bar
&& net use Y: \\192.168.0.2@8081DavWWWRoot /USER:foo bar
&& echo "Your Android phone is now mounted as Windows drive letters"
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Both sdcards mounted
--
Posted to give back to the team as a good Usenet citizen who asks hard
questions which have never been asked before, and who attempts _every_
viable suggestion, and then who gives back to the team not only with the
solution but also with meticulously detailed screenshots so others benefit
from the information found in the permanent record for users to search and
find now
and far into the future.